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ABSTRACT 

Component-based software development has posed a serious chal- 
lenge to system verification since externally-obtained components 
could be a new source of system failures. This issue can not be 
completely solved by either model-checking or traditional software 
testing techniques alone due to several reasons: (1) externally ob- 
tained components are usually unspecified/partially specified; (2) 
it is generally difficult to establish adequacy criteria for testing a 
component; (3) components may be used to dynamically upgrade 
a system. This paper introduces a new approach (called model - 
checking driven black-box testing) that combines model-checking 
with traditional black-box software testing to tackle the problem in 
a complete, sound, and automatic way. The idea is to, with respect 
to some requirement (expressed in CTL or LTL) about the system, 
use model-checking techniques to derive a condition (expressed 
in a communication/witness graph) for an unspecified component 
such that the system satisfies the requirement iff the condition is 
satisfied by the component. The condition's satisfiability can be es- 
tablished by testing the component with test-cases generated from 
the condition on-the-fly. In this paper, we present algorithms for 
model-checking driven black-box testing, which handle both CTL 
and LTL requirements for systems with unspecified components. 
We also illustrate the ideas through some examples. 

Categories and Subject Descriptors 

D.2.4 [Software Engineering]: Software/Program Verification — 
Formal methods, Model-checking; D.2.5 [Software Engineering] : 
Testing/Debugging — Black-box testing; F.4.1 [Mathematic Logic 
and Formal Languages]: Mathematical Logic — Temporal Logic 

General Terms 

Verification, Component-based systems 

Keywords 

Component-based system, Model-checking, Black-box testing 
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1. INTRODUCTION 

Component-based software development 12 II [7] is a systematic 
engineering method to build software systems from prefabricated 
software components that are previously developed by the same or- 
ganization, provided by third-party software vendors, or even pur- 
chased as commercial-off-the-shelf (COTS) products. Though this 
development method has gained great popularity in recent years, it 
has also posed serious challenges to the quality assurance issue of 
component-based software since externally obtained components 
could be a new source of system failures. The issue is of vital 
importance to safety-critical and mission-critical systems. For in- 
stance, in June 1996, during the maiden voyage of the Ariane 5 
launch vehicle, the launcher veered off course and exploded less 
than one minute after taking off. The report 1251 of the Inquiry 
Board indicates that the disaster resulted from insufficiently tested 
software reused from the Ariane 4. The developers had reused cer- 
tain Ariane 4 software component in the Ariane 5 without substan- 
tially testing it in the new system, having assumed that there were 
no significant differences in these portions of the two systems. 

Most of the current work addresses the issue from the viewpoint 
of component developers: how to ensure the quality of components 
before they are released. However, this view is obviously insuffi- 
cient: an extensively tested component (by the vendor) may still not 
perform as expected in a specific deployment environment, since 
the systems where a component could be deployed may be quite 
different and diverse and they may not be tried out by its vendor. 
So, we look at this issue from system developers' point of view: 

(*) how to ensure that a component functions correctly 
in the host system where the component is deployed. 

In practice, testing is almost the most natural resort to resolve this 
issue. When integrating a component into a system, system devel- 
opers may have three options for testing: (1) trust the component 
provider's claim that the component has undergone thorough test- 
ing and then go ahead to use it; (2) extensively retest the component 
alone; (3) hook the component with the system and conduct inte- 
gration testing. Unfortunately, all of the three options have some 
serious limitations. Obviously, for systems requiring high reliabil- 
ity, the first option is totally out of the question. The second option 
may suffer from the following fact. Software components are gen- 
erally built with multiple sets of functionality 1 16 1, and indiscrim- 
inately testing all the functionality of a software component is not 
only expensive but sometimes also infeasible, considering the po- 
tentially huge state space of the component interface. Additionally, 
it is usually difficult to know when the testing over the component 
is adequate. The third option is not always applicable. This is be- 
cause, in many applications, software components could be applied 
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for dynamic upgrading or extending a running system 1 35 1 that is 
costly or not supposed to shut down for retesting at all. Even with- 
out all the above limitations, purely testing-based strategies are still 
not sufficient to establish the solid confidence for a reliable compo- 
nent required by mission-critical or safety-critical systems, where 
formal methods like model-checking are highly desirable. How- 
ever, one fundamental obstacle for using a formal method to ad- 
dress the issue of (*) is that design details or source code of an ex- 
ternally obtained software component is generally not fully avail- 
able to the developers of its host system. Thus, existing formal 
verification techniques (like model-checking) are not directly ap- 
plicable. 

Clearly, this problem plagues both component-based software 
systems and some hardware systems with a modularized design. 
Generally, we call such systems as systems with unspecified compo- 
nents (in fact, in most cases, the components are partially specified 
to which our approach still applies.). 

In this paper, we present a new approach, called model-checking 
driven black-box testing, which combines model-checking tech- 
niques and black-box testing techniques to deal with this problem. 
The idea is simple yet novel: with respect to some temporal re- 
quirement about a system with an unspecified component, a model- 
checking based technique is used to derive automatically a condi- 
tion about the unspecified component from the rest of the system. 
This condition guarantees that the system satisfies the requirement 
iff the condition is satisfied by the unspecified component, which 
can be checked by adequate black-box testing over the unspecified 
component with test-cases generated automatically from the condi- 
tion. 

We provide algorithms for both LTL and CTL model-checking 
driven black-box testing. In the algorithms, the condition men- 
tioned earlier is represented as communication graphs and witness 
graphs, on which a bounded and nested depth-first search procedure 
is employed to run black-box testing over the unspecified compo- 
nent. Our algorithms are both sound and complete. 

Though we do not have an exact complexity analysis result, our 
preliminary studies show that, in the liveness testing algorithm for 
LTL, the maximal length of test-cases run on the component is 
bounded by 0(n ■ m 2 ). For CTL, the length is bounded by 0(k ■ 
n ■ m 2 ). In here, k is the number of CTL operators in the formula 
to be verified, n is the state number in the host system, and m is the 
state number in the component. 

The advantages of our approach are obvious: a stronger confi- 
dence about the reliability of the system can be established through 
both formal verification and adequate functional testing; system de- 
velopers can customize the testing with respect to some specific 
system properties; intermediate model-checking results (the com- 
munication and witness graphs) can be reused to avoid (repetitive) 
integration testing when the component is updated, if only the new 
component's interface remains the same; our algorithms are both 
sound and complete; most of all, the whole process can be carried 
our in an automatic way. 

The rest of this paper is organized as follows. Section|2|provides 
some background on temporal logics LTL and CTL along with our 
model of systems containing unspecified components. The main 
body of the paper consists of Section|3|and Section|4| which pro- 
pose algorithms for LTL and CTL model-checking driven black- 
box testing, respectively, over the system model. Section [5] illus- 
trates the algorithms through an example. Section |5| lists some of 
the related work. Section^concludes the paper with some further 
issues to be resolved in the future. 

Details on some algorithms are omitted in this extended abstract. 
At http://www.eecs.wsu.edu/~gxie a full version of this paper is 



available. 

2. PRELIMINARIES 
2.1 The System Model 

In this paper, we consider systems with only one unspecified 
component (the algorithms generalize to systems with multiple un- 
specified components). Such a system is denoted by 

Sys = (M,X), 

where M is the host system and X is the unspecified component. 
Both M and X are finite-state transition systems communicating 
synchronously with each other via a finite set of input and output 
symbols. 

Formally, the unspecified component X is defined as a deter- 
ministic Mealy machine whose internal structure is unknown (but 
an implementation of X is available for testing). We write X as 
a triple (E, V, m), where E is the set of X's input symbols, V is 
the set of X's output symbols, and m is an upper bound for the 
number of states in X (as a convention in black-box testing, the m 
is given). Assume that X has an initial state Sinit- A run of X is 
a sequence of symbols alternately in E and V: aoflo&ifli..., such 
that, starting from the initial state Sinit, X outputs exactly the se- 
quence Pof3\... when it is given the sequence aocti... as input. In 
this case, we say that the input sequence is accepted by X. 

The host system M is defined as a 5-tuple 

, r, Renv , Rcomm , -^) 

where 

• S is a finite set of states; 

• r is a finite set of events; 

• Renv Q S X r x S defines a set of environment transitions 
where (s, a, s') G Renv means that M moves from state s 
to state s' upon receiving an event (symbol) a G T from the 
outside environment; 

• Rcomm Q S'xExVxS' defines a set of communica- 
tion transitions where (s, a, /3, s') G Rcomm means that M 
moves from state s to state s' when X outputs a symbol 
/3 G V after M sends X an input symbol a G E; and, 

• I C S is A/'s initial states. 

Without loss of generality, we further assume that, there is only one 
transition between any two states in M (but M, in general, could 
still be nondeterministic). 

An execution path of the system Sys — {M, X) can be repre- 
sented as a (potentially infinite) sequence r of states and symbols, 
S0C0S1C1..., where each Si G S, each Ci is either a symbol in V or 
a pair ctifii (called a communication) with G E and f3i G V. 
Additionally, r satisfies the following requirements: 

• so is an initial state of M, i.e., so G /; 

• for each Cj G T, (sj, a, s^+i ) is an environment transition of 

M; 

• for each c,: = ctifli, (si,at, /3i, s^+i) is a communication 
transition of M. 

The communication trace of r, denoted by tx, is the sequence 
obtained from r by retaining only symbols in E and V (i.e., the 
result of projecting r onto E and V). For any given state s G S, 
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we say that the system Sys can reach s iff Sys has an execution 
path t on which s appears and tx (if not empty) is also a run of X. 

In the case when X is fully specified, the system can be regarded 
as an I/O automaton [26|. 

2.2 Model-checking 

Model-checking(9] 1331 1101 1361 1201 is an automatic technique 
for verifying a finite-state system against some temporal specifi- 
cation. The system is usually represented by a Kripke structure 
K — (S, R, L) over a set of atomic propositions AP, where 

• S is a finite set of states; 

• R C S x S is the (total) transition relation; 

• L : S — > 2 AP is a function that labels each state with the set 
of atomic propositions that are true in the state. 

The temporal specification can be expressed in, among others, 
a branching-time temporal logic (CTL) or a linear-time temporal 
logic (LTL). Both CTL and LTL formulas are composed of path 
quantifiers A and E, which denote "for all paths" and "there ex- 
ists a path", respectively, and temporal operators X, F, U and G, 
which stands for "next state", "eventually", "until", and "always", 
respectively. 

More specifically, CTL formulas are defined as follows: 

• Constants true and false, and every atomic proposition in 
AP are CTL formulas; 

• If ft and ft are CTL formulas, then so are -i/i, ft A ft, ft V 
ft, ft -» ft, EX ft, AX ft, EF ft, AF ft, E[ft U ft], 
A[fi U ft], EG ft, AG f x . 

Due to duality, any CTL formula can be expressed in terms of 
-i, V, EX, EU and EG. A CTL model-checking problem, formu- 
lated as 

, is to check whether the CTL formula / is true at a state s. For 
example, AF f is true at state s if / will be eventually true on all 
paths from s; E[f U g] is true at state s if there exists a path from 
s on which / is true at each step until g becomes true. 

LTL formulas, on the other hand, are all in the form of A f where 
/ is a path formula defined as follows: 

• Constants true and false, and every atomic proposition in 
AP are path formulas; 

• If ft and ft are path formulas, then so are -i/i, ft Aft, 
ft V ft, X ft, F ft, [ft U ft], G ft. 

An LTL model-checking problem, formulated as 

K,s |= Af 

, is to check whether the path formula / is true on all paths from 
a state s. For example, AFG f is true at s if on all paths from s, 
after a future point / will be always true; AGF f is true at s if on 
all paths from s, f will be true infinitely often. 

More detailed background in model-checking and temporal log- 
ics can be found in the textbook 1 1 1 1. The system Sys = {M, X) 
defined earlier can be understood as a Kripke structure (with a given 
labeling function and atomic propositions over states in M ). Since 
X is an unspecified component, in the rest of the paper, we mainly 
focus on how to solve the LTL/CTL model-checking problems on 
the Sys through black-box testing on X. 



2.3 Black-box Testing 

Black-box testing (also called functional testing) is a technique 
to test a system without knowing its internal structure. The sys- 
tem is regarded as a "black-box" in the sense that its behaviour 
can only be determined by observing (i.e., testing) its input/output 
sequences. As a common assumption in black-box testing, the un- 
specified component X (treated as a black-box) has a special input 
symbol reset which always makes X return to its initial state re- 
gardless of its current state. We use Experiment(X ,resetn) to 
denote the output sequence obtained from the input sequence it, 
when X runs from the initial state (caused by the reset). After 
running this Experiment, suppose that we continue to run X by 
providing an input symbol a following the sequence 7r. Corre- 
sponding to this a, we may obtain an output symbol f3 from X. 
We use Experiment(X , a) to denote the (3. Notice that this latter 
Experiment is a shorthand for "the last output symbol in 
ExperimentiX , resetna)" . 

Studies have shown that if only an upper bound for the number 
of states in the system and the system's inputs set are known, then 
its (equivalent) internal structure can be fully recovered through 
black-box testing. Clearly, a naive algorithm to solve the LTL/CTL 
model-checking problem over the Sys is to first recover the full 
structure of the component X through testing, and then to solve 
the classic model-checking problem over the fully specified system 
composed from M and the recovered X. Notice that, in the naive 
algorithm, when we perform black-box testing over X, the selected 
test-cases have nothing to do with the host system M. Therefore, 
it is desirable to find more sophisticated algorithms such as the 
ones discussed in this paper, that only select "useful" test-cases wrt 
the M as well as the temporal specification of M that needs to be 
checked. 

3. LTL MODEL-CHECKING DRIVEN 
BLACK-BOX TESTING 

In this section, we introduce algorithms for LTL model-checking 
driven black-box testing for the system Sys = (M, X) defined 
earlier. We first show how to solve a liveness analysis problem. 
Then, we discuss the general LTL model-checking problem. 

3.1 Liveness Analysis 

The liveness analysis problem (also called the infinite-often prob- 
lem) is to check: starting from some initial state so 6 I, whether 
the system Sys can reach a given state s / for infinitely many times. 

When M has no communications with the unspecified compo- 
nent X, solving the problem is equivalent to finding a path p that 
runs from so to Sf and a loop C that passes s/. However, as far 
as communications are involved, the problem gets more compli- 
cated. The existence of the path p does not ensure that the system 
can indeed reach s/ from so (e.g., communications with X may 
never allow the system to take the necessary transitions to reach 
Sf). Moreover, the existence of the loop C does not guarantee that 
the system can run along C forever either (e.g., after running along 
C for three rounds, the system may be forced to leave C by the 
communications with X). 

We approach this infinite-often problem in three steps. First, we 
look at whether a definite answer to the problem is possible. If we 
can find a path from so to Sf and a loop from Sf to s f that involve 
only environment transitions, then the original problem (i.e., the 
infinite-often problem) is definitely true. If such a path and a loop, 
no matter what transitions they may involve, do not exist at all, 
then the original problem is definitely false. If no definite answer 
is possible, we construct a directed graph G and use it to generate 
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test-cases for the unspecified component X. The graph G, called 
a communication graph, is a subgraph of M, represents all paths 
and loops in M that could witness the truth of the problem (i.e., 
paths that run from so to s/ and loops that pass Sf). The graph G 
is defined as a pair (N, E), where N is a set of nodes and E is a 
set of edges. Each edge of G is annotated either by a pair a/3 that 
denotes a communication of M with X, or has no annotation. We 
construct G as follows. 

• Add one node to G for each state in M that is involved in 
some path between so and s f or in a loop that passes s/; 

• Add one edge between two nodes in N if M has a transition 
between two states corresponding to the two nodes respec- 
tively. If the transition involves a communication with X, 
then annotate the edge with the communication symbols. 

It is easy to see that the liveness analysis problem is true if and only 
if the truth is witnessed by a path in G. Therefore, the last step is 
to check whether G has a path along which the system can reach 
s f from so first and then reach s / for infinitely many times. More 
details of this step are addressed in the next subsection. 
See appendix IB. ll for details on the above operations. 

3.2 Liveness Testing 

To check whether the constructed communication graph G has a 
path that witnesses the truth of the original problem, the straightfor- 
ward way is to try out all paths in G and then check, whether along 
some path, the system can reach s / from so first and then reach s / 
for infinitely many times. The check is done by testing X with the 
communication trace of the path to see whether it is a run of X. 
However, one difficulty is that G may contain loops, and certainly 
we can only test X with a finite communication trace. Fortunately, 
the following observations are straightforward: 

• To check whether the system can reach s f from so, we only 
need to consider paths with length less than rn.ni where m is 
the maximal number of communications on all simple paths 
(i.e., no loops on the path) between so and s/ in G, and m 
is an upper bound for the number of states in the unspecified 
component X; 

• To check whether the system can reach from Sf to Sf for 
infinitely many times, we only need to make sure that the 
system can reach Sf for m — 1 times, and between s f and 
s / , the system goes through a path no longer than that is 
the maximal number of communications on all simple loops 
(i.e., no nested loops along the loop) in G that pass s/. 

Letn = max{n\,n2). The following procedure TestLiveness 
uses a bounded and nested depth-first search to traverse the graph 
G while testing X. It first tests whether the system can reach Sf 
from so along a path with length less than mn, then it tests whether 
the system can further reach s/ to s / for m — 1 more times. The 
algorithm maintains a sequence of input symbols that has been suc- 
cessfully accepted by X, an integer variable level that records how 
many communications have been gone through without reaching 
Sf, and an integer variable count that indicates how many times 
s / has been reached. At each step, it chooses one candidate from 
the set of all possible input symbols at a node, and feeds the in- 
put sequence concatenated with the candidate input symbol to X. 
If the candidate input symbol and the output symbol (correspond- 
ing to the candidate input symbol) of X match the annotation of an 
edge originating from the node, the procedure moves forward to try 
the destination node of the edge with level increased by 1. If there 



is no match, then the procedure tries other candidates. But before 
trying any other candidate, we need to bring X to its initial state by 
sending it the special input symbol reset. The procedure returns 
false when all candidates are tried without a match, or when more 
than mn communications have been gone through without reach- 
ing s / . After s / is reached, the procedure increases count by 1 and 
resets level to 0. The procedure returns true when it has already 
encountered s / for m times. 

Procedure TestLiveness(X,-K , so, Sf, level, count) 
If level > mn Then 

Return false; 
Else If s = Sf Then 
If count >— m Then 

Return true; 
Else 

count := count + 1; level := 0; 
For each (s , s') £ E Do 
Experiment(X , resetn) ; 

If TestLiveness(X, -k, s' , Sf,level, count) Then 
Return true; 
Inputs := {q|(so, a/3, s') £ E}; 
For each a £ Inputs Do 

Experiment(X, resetn); 
(3 := ExperimentiX , a); 
If 3s' : {s ,af3,s') £ E Then 

If TestLiveness(X,na, s' , Sf, level + 1, count) 
Then Return true; 
Return false. 

In summary, our liveness testing algorithm to solve the liveness 
analysis problem has two steps: (1) build the communication graph 
G; (2) return the truth of 

TestLiveness(X, reset, so, Sf, level — 0, count = 0). 

3.3 LTL Model-Checking Driven Testing 

Recall that the LTL model-checking problem is, for a Kripke 
structure K = {S, R, L) with a state s £ S and a path formula /, 
to determine if K, s \= A f. Notice that K , s \= A f if and only if 
K, s \= -iE -if. Therefore it is sufficient to only consider formulas 
in the form E f. The standard LTL model-checking algorithm 1 1 1 1 
first constructs a tableau T for the path formula /. T is also a 
Kripke structure and includes every path that satisfies /. Then the 
algorithm composes T with K and obtains another Kripke structure 
P which includes exactly the set of paths that are in both T and K. 
Thus, a state in K satisfies E f if and only if it is the start of a path 
(in the composition P) that satisfies /. 

Define sat(f) to be the set of states in T that satisfy / and use 
the convention that (s, s') £ sat(f) if and only if s' £ sat(f). The 
LTL model-checking problem can be summarized by the following 
theorem [ 111 : 

THEOREM 1. K, s \= E f if and only if there is a state s' in 
T such that (s, s') £ sat(f) and P, (s, s') |= EG true under 
fairness constraints {sat(—>(g U h) V h) \ g U h occurs in /}. 

Note that the standard LTL model-checking algorithm still ap- 
plies to the system Sys = (M, X), although it contains an unspec- 
ified component X. To see this, the construction of the tableau T 
from / and the definition of sat are not affected by the unspecified 
component X. The composition of Sys and T is a new system 
Sys' — (P, X) where P is the composition of M and T . Then 
one can show 

COROLLARY 1. (M, X),s \= E f if and only if there is a state 
s' in T such that (s, s') £ sat(f) and {P, X), (s, s') |= EG true 
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under fairness constraints {sat(-^(g U h) V h) \ g U h occurs in 
/}■ 

Obviously, checking whether there is a state s' in T such that 
(s, s') G sat(f) is trivial. To check whether (P, X) , (s, s') |= 
_BG irtte under the fairness constraints is equivalent to checking 
whether there is computation in {P, X) that starts from (s, s') and 
on which the fairness constraints are true infinitely often. One 
can show that this is equivalent to the liveness analysis problem 
we studied in the previous subsection, and thus, the LTL model- 
checking problem can be solved by extending our algorithms for 
the liveness analysis problem. Moreover, the algorithms are both 
complete and sound. 

4. CTL MODEL-CHECKING DRIVEN 
BLACK-BOX TESTING 

In this section, we introduce algorithms for CTL model-checking 
driven black-box testing for the system Sys = (M, X). 

4.1 Ideas 

Recall that the CTL model-checking problem is, for a Kripke 
structure K — (S, R,L), a state so G S, and a CTL formula /, 
to check whether K, so \= f holds. The standard algorithm 1 1 1 1 
for this problem operates by searching the structure and, during the 
search, labeling each state s with the set of subformulas of / that 
are true at s. Initially, labels of s are just L(s). Then, the algorithm 
goes through a series of stages — during the i-th stage, subformulas 
with the (i — l)-nested CTL operators are processed. When a sub- 
formula is processed, it is added to the labels for each state where 
the subformula is true. When all the stages are completed, the algo- 
rithm returns true when so is labeled with /, or false otherwise. 

However, if a system is not completely specified, the standard 
algorithm does not work. This is because, in the system Sys = 
(M, X), transitions of M may depend on communications with the 
unspecified component X. In this section, we adapt the standard 
CTL model-checking algorithm 1 1 1 1 to handle the system Sys (i.e., 
to check whether 

{M,X),s \=f 

holds where so is an initial state in M and / is a CTL formula over 
M). 

The new algorithm follows a structure similar to the standard 
one. It also goes through a series of stages to search M's state 
space and label each state during the search. However, during a 
stage, processing the subformulas is rather involved, since the truth 
of a subformula h at a state s can not be simply decided (it may de- 
pend on communications). Similar to the algorithm for the liveness 
analysis problem, our ideas here are to construct a graph represent- 
ing all the paths that witness the truth of h at s. But, the new al- 
gorithm is far more complicated than the liveness testing algorithm 
for LTL, since the truth of a CTL formula is usually witnessed by a 
tree instead of a single path. In the new algorithm, processing each 
subformula h is sketched as follows. 

When h takes the form of EX g, E[gi U g 2 ], or EG g, we con- 
struct a graph that represents exactly all the paths that witness the 
truth of h at some state. We call such a graph the subformula's wit- 
ness graph (WG), written as [/i]. We also call [/i] an EX graph, an 
EU graph, or an EG graph if h takes the form of EX g, E[g\ U g 2 ], 
or EG g, respectively. 

Let k be the total number of CTL operators in /. In the algo- 
rithm, we construct k WGs, and for each WG, we assign it with a 
unique ID number that ranges between 2 and k + 1. (The ID num- 
ber 1 is reserved for constant true.) Let I be the mapping from 



the WGs to their IDs; i.e., denotes the ID number of h's 

witness graph, and 1 (i) denotes the witness graph with i as its 
ID number, 1 < i < k + 1. We label a state s with ID number 1 
if h is true at s and the truth does not depend on communications 
between M and X. Otherwise, we label s with 2<i<fc+lif 
h could be true at s and the truth would be witnessed only by some 
paths which start from s in X -1 (i) and, on which, communications 
are involved. 

When h takes the form of a Boolean combination of subformulas 
using -1 and V, the truth of h at state s is also a logic combination of 
the truths of the component subformulas at the same state. To this 
end, we label the state with an ID expression ip defined as follows: 

• ID := 1 1 2 I ... I fc + 1; 

• ip := ID I -vip [ tp V tp. 

Let ^ denote the set of all ID expressions. For each subformula h, 
we construct a labeling (partial) function Lh : 5* — » to record 
the ID expression labeled to each state during the processing of 
the subformula h, and the labeling function is returned when the 
subformula is processed. 

The detailed procedure, called ProcessCTL, for processing 
subformulas will be given in Section H^l After all subformulas are 
processed, a labeling function Lf for the outer-most subformula 
(i.e., / itself) is returned. The algorithm returns true when s is la- 
beled with 1 by Lf. It returns false when s is not labeled at all. In 
other cases, a testing procedure over X is applied to check whether 
the ID expression labeled in i/(s) could be evaluated true. The 
procedure, called TestWG, will be given in Section l43l In sum- 
mary, the algorithm (to solve the CTL model-checking problem 
(M, X), so |= /) is sketched as follows: 

Procedure CheckCTL(M, X, s , /) 
L f := ProcessCTL(M, f) 
If so is labeled by Lf Then 
If L f (s ) = 1 Then 

Return true; 
Else 

Return TestWG(X, reset, so, I// (so)); 
Else (i.e., so is not labeled at all) 
Return false. 

4.2 Processing a CTL formula 

Processing a CTL formula h is implemented through a recur- 
sive procedure ProcessCTL. Recall that any CTL formula can be 
expressed in terms of V, -1, EX, EU, and EG. Thus, at each inter- 
mediate step of the procedure, depending on whether the formula h 
is atomic or takes one of the following forms: g\ V 32, ^g, EX g, 
E[gi U gn], or EG g, the procedure has only six cases to consider 
and when it finishes, a labeling function Lh is returned for formula 
h. 

Procedure ProcessCTL(M, h) 
Case 

h is atomic: Let Lh label every state with 1 
whenever h is true on the state; 



gi V g 2 : 




Lgi := 


= ProcessCTL(M, 31); 


L 92 :- 


= ProcessCTL(M, g 2 ); 


L h := 


HandleU nion(L gi , L g2 ) 


L g := 


ProcessCTL(M,g); 


L h := 


H andleN egation(M , L g 


EXg: 




L g := 


ProcessCTL(M, g); 
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L h := 


= HandleEX(M,L g ); 


h = E [gi U 


92] • 




= ProcessCTL(M,gi); 


L g2 : 


= ProcessCTL(M,g 2 ); 


L h := 


= HandleEU {M, L gi , L 92 


h = EGg: 




L a := 


= ProcessCT L(M,g); 


L h := 


-- HandleEG(M, L g ); 



Return L h . 

In the above procedure, when h — ji Vj2,we first process gi and 
32 respectively by calling ProcessCTL, then construct a labeling 
function Lh for /i by merging (i.e., HandleUnion, see Appendix 
IB. 21 for details)) g 1 and (/2's labeling functions L gi and L 92 as 
follows: 

• For each state s that is in both L gi 's domain and L g2 's do- 
main, let Lh label s with 1 if either L gi or L S2 labels s with 
1 and label s with ID expression L gi (s) V I/ 92 (s) otherwise; 

• For each state s that is in L gi 's domain (resp. L g2 's domain) 
but not in L g2 's domain (resp. L gi 's domain), let L label s 
with L gi (s) (resp. L S2 (s)). 

When /i = -15, we first process g by calling ProcessCTL, 
then construct a labeling function Lh for /i by "negating" (i.e., 
HandleNegation, see Appendix lB . 3 I f or details)) g's labeling func- 
tion L g as follows: 

• For every state s that is not in the domain of L g , let Lh label 
s with 1; 

• For each state s that is in the domain of L g but not labeled 
with 1 by Lg, let Lh label s with ID expression -iL g (s). 

The remaining three cases (i.e., for EX, EU, and EG) in the 
above procedure are more complicated and are handled in the fol- 
lowing three subsections respectively. 

4.2.1 Handling EX 

When h = EXg, g is processed first by ProcessCTL. Then, 
the procedure HandleEX is called with g's labeling function L g 
to construct a labeling function Lh and create a witness graph for h 
(we assume that, whenever a witness graph is created, the current 
value of a global variable id, which initially is 2, is assigned as 
the ID number of the graph, and id is incremented by 1 after it is 
assigned to the graph). 

The labeling function Lh is constructed as follows. For each 
state s that has a successor s' in the domain of L g , if s can reach 
s' through an environment transition and s' is labeled with 1 by L g 
then let Lh also label s with 1, otherwise let Lh label s with the 
current value of the global variable id. 

The witness graph for h = EXg, called an EX graph, is created 
as a triple: 

M = (N,E, Lg), 

where N is a set of nodes and E is a set of annotated edges. It is 
created as follows: 

• Add one node to N for each state that is in the domain of L g . 

• Add one node to N for each state that has a successor in the 
domain of L g . 

• Add one edge between two nodes in N to E when M has a 
transition between two states corresponding to the two nodes 
respectively; if the transition involves a communication with 
X then annotate the edge with the communication symbols. 



When HandleEX finishes, it increases the global variable id by 1 
(since one new witness graph has been created). 
See Appendix lB ,4l for details. 

4.2.2 Handling EU 

The case when h = E [gi U 32] is more complicated. We first 
process g\ and gi respectively by calling ProcessCTL, then call 
procedure HandleEU with g\ and g 2 's labeling functions L gi and 
L g2 to construct a labeling function Lh and create a witness graph 
for h. 

We construct the labeling function Lh recursively. First, let Lh 
label each state s in the domain of L g2 with L 92 (s). Then, for 
state s that has a successor s' in the domain of Lh, if both s and 
s' is labeled with 1 by L gi and Lh respectively and s can reach s' 
through an environment transition then let Lh also label s with 1, 
otherwise let Lh label s with the current value of the global variable 
id. Notice that, in the second step, if a state s can be labeled with 
both 1 and the current value of id, let Lh label s with 1. Thus, we 
can ensure that the constructed Lh is indeed a function. 

The witness graph for h, called an EU graph, is created as a 
4-tuple: 

(h] := (N,E,L gi ,L g2 ), 

where N is a set of nodes and E is a set of edges. N is constructed 
by adding one node for each state that is in the domain of Lh, while 
E is constructed in the same way as that of HandleEX . When 
HandleEU finishes, it increases the global variable id by 1. 
See Appendix lB ,5l for details. 

4.2.3 Handling EG 

To handle formula h — EGg, we first process g by calling 
ProcessCTL, then call procedure HandleEG with g's labeling 
function L g to construct a labeling function Lh and create a witness 
graph for h. 

The labeling function Lh is constructed as follows. For each 
state s that can reach a loop C through a path p such that every 
state (including s) on p and C is in the domain of L g , if every state 
(including s) on p and C is labeled with 1 by L g and no commu- 
nications are involved on the path and the loop, then let Lh also 
label s with 1, otherwise let Lh label s with the current value of the 
global variable id. 

The witness graph for h, called an EG graph, is created as a 
triple: 

lh] := (N,E,L g ), 

where N is a set of nodes and E is a set of annotated edges. The 
graph is constructed in a same way as that of HandleEU. When 
HandleEG finishes, it also increases the global variable id by 1. 
See Appendix lB ,6l for details. 

4.3 Testing a Witness Graph 

As mentioned in Section l4Tl the procedure for CTL model- 
checking driven black-box testing, CheckCTL, consists of two 
parts. The first part, which was discussed in Section l4l2l includes 
ProcessCTL that processes CTL formulas and creates witness 
graphs. The second part is to evaluate the created witness graphs 
through testing X. We will elaborate on this second part in this 
section. 

In processing the CTL formula /, a witness graph is constructed 
for each CTL operator in / and a labeling function is constructed 
for each subformula of /. As seen from the algorithm CheckCTL 
(at the end of Section l4~Ti . the algorithm either gives a definite 
"yes" or "no" answer to the CTL model-checking problem, i.e., 
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{M, X), so |= /, or it reduces the problem to checking whether 
the ID expression tp labeled to so can be evaluated true at the state. 
The evaluation procedure is carried out by the following recursive 
procedure TestWG, after an input sequence tt has been accepted 
by the unspecified component X. 



Procedure TestWG(X, tt, s ,ip) 
Case 

JtTestWG(X, 7t, so, ipi) Then 

Return true; 
Else 

Return TestWG(X, tt, s , ip 2 ) 
V> = -rtpi : 

Return -<TestWG(X, ir,s ,tpi) 
■0 = 1: 

Return true; 
ip = i with 2 < i < k + 1: 

When I -1 (i) is an graph 

Return TestEX(X, tt, so,! -1 (i)); 
When is an £??7 graph 

ReturnTestEt/pf^so,:!" 1 ^).^/ = 0); 
When I -1 (i) is an i5G graph 

Return TestEG(X, tt, so,X _1 (i)). 
In TestWG, the first three cases are straightforward, which are 
consistent with the intended meaning of ID expressions. The cases 
TestEX, TestEU, TestEG for evaluating EX, EU, EG graphs 
are discussed in the following three subsections. 

4.3.1 TestEX 

The case for checking whether an EX graph G = {N, E, L g ) 
can be evaluated true at a state so is simple. We just test whether 
the system M can reach from so to another state s' g dom(L 9 ) 
through a transition in G such that the ID expression L g (s') can be 
evaluated true at a' . 

See Appendix lB.7l for details. 

4.3.2 TestEU 

To check whether an EU graph G = {N, E, L gi , L 32 ) can be 
evaluated true at a state so, we need to traverse all paths p in G with 
length less than mn and test the unspecified component X to see 
whether the system can reach some state s' £ dom(L 92 ) through 
one of those paths. In here, m is an upper bound for the number 
of states in the unspecified component X and n is the maximal 
number of communications on all simple paths between so and s'. 
In the meantime, we should also check whether L g2 (s') can be 
evaluated true at s' and whether L gi (si) can be evaluated true at Si 
for each s; on p (excluding s') by calling TestWG. 

See Appendix lB.8l for details. 

4.3.3 TestEG 

For the case to check whether an EG graph G = (N, E, L g ) 
can be evaluated true at a state so, we need to find an infinite path 
in G along which the system can run forever. 

The following procedure TestEG first decomposes G into a set 
of SCCs. Then, for each state s/ in the SCCs, it calls another 
procedure SubTestEG to test whether the system can reach Sf 
from so along a path not longer than mn, as well as whether the 
system can further reach s f from s/ for m — 1 times. The basic idea 
of SubTestEG (see Appendix lB ,9l for details) is similar to that of 
the TestLiveness algorithm in Section l3l2l except that we need 
also check whether L g (si) can be evaluated true at Si for each state 



Si that has been reached so far by calling TestWG. Here, m is the 
same as before while n is the maximal number of communications 
on all simple paths between so and Sf. 

Procedure TestEG{X,n, s , G = (N,E,L g )) 
SCC := {C\C is a nontrivial SCC of G}; 

T: = UctsccW 8 e C}; 
For each s e T Do 

Experiment(X, resetir); 

If SubTestEG(X,ir, so, s,G, level = 0, count = 0); 
Return true; 
Return false. 

In summary, to solve the CTL model-checking problem 

(M,X),s \= f, 

our algorithm CheckCTL in Section l4Tl either gives a definite 
yes/no answer or gives a sufficient and necessary condition in the 
form of ID expressions and witness graphs. The condition is evalu- 
ated through black-box testing over the unspecified component X. 
The evaluation process will terminate with a yes/no answer to the 
model-checking problem. One can show that our algorithm is both 
complete and sound. 

5. EXAMPLES 

In this section, to better understand our algorithms, we look at 
some examples . 




Figure 1 

Consider a system Sys = (M, X) where M keeps receiving 
messages from the outside environment and then transmits the mes- 
sage through the unspecified component X. The only event symbol 
in M is msg, while X has two input symbols send and ack, and 
two output symbols yes and no. The transition graph of M is de- 
picted in Figure 1 where we use a suffix ? to denote events from 
the outside environment (e.g., msg?), and use a infix / to denote 
communications of M with X (e.g., send /yes). 

Assume that we want to solve the following LTL model-checking 
problem 

(M,X),s ^EGFs 2 

i.e., starting from the initial state so, the system can reach state si 
infinitely often. Applying our liveness analysis algorithms, we can 
obtain the (minimized) communication graph in Figure 2. 

send/yes ^ 

®^=^@ 

Figure 2 

From this graph and our liveness testing algorithms, the system 
satisfies the liveness property iff the communication trace 

send yes(send yes ack yes)" 1-1 

'The transition graphs in the figures in this section are not made 
total for the sake of readability. 
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is a run of X, where m is an upper bound for number of states 
in X. Now, we slightly modified the transition graph of M into 
Figure 3 such that when a send fails, the system shall return to the 
initial state. 




ack/yes 



msg.' 



s41 



sr 



send/yes 



send/no 



ack/yes 



msg.' 



Figure 6 



s2) 



ack/yes 



Figure 3 

For this modified system, its (minimized) communication graph 
with respect to the liveness property would be as shown in Figure 
4. 

send/no 



send/yes 




ack/yes 



Figure 4 



From Figure 4 and the liveness testing algorithms, the system 
satisfies the liveness property iff there exist < fei, fca < 2m such 
that the communication trace 



{send no) kl send yes((send yes ack yes)(send no 



^2\w-l 



is a run of X. 

Still consider the system in Figure 3, but we want to solve a CTL 
model-checking problem (M, X), so \= AFs2\ i.e., along all paths 
from so, the system can reach state Si eventually. The problem is 
equivalent to 

{M,X),s \=^EG^s 2 . 

Applying our CTL algorithms to formula h = EG-1S2, we con- 
struct an EG witness graph G = (N, E, Ltrue) whose ID number 
is 2 and a labeling function L^, where L tr ue labels all three states 
so,si, and S3 with ID expression 1 (as defined in Section l4~T1 which 
stands for true), and Lh labels all three states so, si, and S3 with 
2. The graph G is depicted in Figure 5. From this graph as well 
as Lh, the algorithms conclude that the model-checking problem is 
true iff the communication trace (send no) m ~ is not a run of X. 
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send/no 

Figure 5 

Now we modify the system in Figure 1 into a more complicated 
one shown in Figure 6. For this system, we want to check 

(M,X),s \=^E[-^s 2 Us 3 ] 

i.e., starting from the initial state so, the system should never reach 
state S3 earlier than it reaches S2. Applying our CTL algorithms to 
formula 

h = E[^s 2 Us 3 }, 

we obtain an EU witness graph G = (N, E, L\, L2) whose ID 
number is 2 and a labeling function Lh, where L\ labels all four 



states so, si, S3 and S4 with 1, L2 just labels S3 with 1, and Lh 
labels states so, si, and S4 with 2, and labels S3 with 1. The graph 
G is depicted in Figure 7. From this graph as well as Lh, the algo- 
rithms conclude that the model-checking problem is true iff none of 
communication traces in the form of send noiack yes send no)* 
and with length less than 3m is a run of X. 




ack/yes 



Figure 7 

For the same system, we could consider more complicated tem- 
poral properties as follows: 

• (M, X) \= AG(s2 —> AFS3); i.e., starting from the initial 
state so, whenever the system reaches S2, it would eventually 
reach S3. 

• (M,X),s \= AG(s 2 -» AXA[->S2Us 3 J); i.e., starting 
from the initial state so, whenever it reaches state S2, the 
system should never reach S2 again until it reaches S3. 

We do not include the witness graphs and labeling functions for 
these two cases in this extended abstract. Nevertheless, it can be 
concluded that the two problems are true iff no communication 
traces with two consecutive symbol pairs (send yes) can be runs 
of X. 

See Appendix IC . 1 1 and Appendix IC . 2l f or details about the above 
two examples. 

6. RELATED WORK 

The quality assurance problem for component-based software 
has attracted lots of attention in the software engineering commu- 
nity, as witnessed by recent publications in conferences like ICSE 
and FSE. However, most of the work is based on the traditional 
testing techniques and considers the problem from the viewpoint 
of component developers; i.e., how to ensure the quality of compo- 
nents before they are released. 

Voas 1 37 38 1 proposed a component certification strategy with 
the establishment of independent certification laboratories perform- 
ing extensive testing of components and then publishing the results. 
Technically, this approach would not provide much improvement 
for solving the problem, since independent certification laborato- 
ries can not ensure the sufficiency of their testing either, and a 
testing-based technique alone is not enough to a reliable software 
component. Some researchers 1 34 28 1 suggested an approach to 
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augment a component with additional information to increase the 
customer's understanding and analyzing capability of the compo- 
nent behavior. A related approach 1 39 1 is to automatically extract a 
finite-state machine model from the interface of a software compo- 
nent, which is delivered along with the component. This approach 
can provide some convenience for customers to test the component, 
but again, how much a customer should test is still a big problem. 
To address the issue of testing adequacy, Rosenblum defined in 1 32 1 
a conceptual basis for testing component-based software, by intro- 
ducing two notions of C -adequate- for-V and C -adequate-far- M 
(with respect to certain adequacy criteria) for adequate unit testing 
of a component and adequate integration testing for a component- 
based system, respectively. But this is still a purely testing-based 
strategy. In practice, how to establish the adequacy criteria is an 
unclear issue. 

Recently, Bertolino et. al. 1 5 1 recognized the importance of test- 
ing a software component in its deployment environment. They 
developed a framework that supports functional testing of a soft- 
ware component with respect to customer's specification, which 
also provides a simple way to enclose with a component the devel- 
oper's test suites which can be re-executed by the customer. Yet 
their approach requires the customer to have a complete specifica- 
tion about the component to be incorporated into a system, which is 
not always possible. McCamant and Ernst 1271 considered the issue 
of predicting the safety of dynamic component upgrade, which is 
part of the problem we consider. But their approach is completely 
different since they try to generate some abstract operational ex- 
pectation about the new component through observing a system's 
run-time behavior with the old component. 

In the formal verification area, there has been a long history of 
research on verification of systems with modular structure (called 
modular verification [ 3 1 1 ) . A key idea 1 23 1 8 1 in modular verifica- 
tion is the assume -guarantee paradigm: A module should guaran- 
tee to have the desired behavior once the environment with which 
the module is interacting has the assumed behavior. There have 
been a variety of implementations for this idea (see, e.g., 1 2 1). How- 
ever, the assume-guarantee idea does not immediately fit with our 
problem setup since it requires that users must have clear assump- 
tions about a module's environment. 

In the past decade, there has also been some research on com- 
bining model-checking and testing techniques for system verifi- 
cation, which can be classified into a broader class of techniques 
called specification-based testing. But most of the work only uti- 
lizes model-checkers' ability of generating counter-examples from 
a system's specification to produce test cases against an implemen- 
tation GDEDiniElEllslEl. 

Peled et. al. I30II17| |29I studied the issue of checking a black- 
box against a temporal property (called black-box checking). But 
their focus is on how to efficiently establish an abstract model of 
the black-box through black-box testing , and their approach re- 
quires a clearly-defined property (LTL formula) about the black- 
box, which is not always possible in component-based systems. 
Kupferman and Vardi |22| investigated module checking by con- 
sidering the problem of checking an open finite-state system under 
all possible environments. Module checking is different from the 
problem in (*) mentioned at the beginning of the paper in the sense 
that a component understood as an environment in 1221 is a spe- 
cific one. Fisler et. al. 1141 124 proposed an idea of deducing 
a model-checking condition for extension features from the base 
feature, which is adopted to study model-checking feature-oriented 
software designs. Their approach relies totally on model-checking 
techniques; their algorithms have false negatives and do not handle 
LTL formulas. 



7. DISCUSSIONS 

In this paper, we present algorithms for LTL and CTL model- 
checking driven black-box testing. The algorithms create commu- 
nication graphs and witness graphs, on which a bounded and nested 
depth-first search procedure is employed to run black-box testing 
over the unspecified component. Our algorithms are both sound 
and complete. Though we do not have an exact complexity analy- 
sis result, our preliminary studies show that, in the liveness testing 
algorithm for LTL, the maximal length of test-cases fed into the 
unspecified component X is bounded by 0(n ■ m 2 ). For CTL, the 
length is bounded by 0(k ■ n ■ ra 2 ). In here, k is the number of 
CTL operators in the formula to be verified, n is the state number 
in the host system, and m is the state number in the component. 

The next natural step is to implement the algorithms and see how 
well they work in practice. In the implementation, there are further 
issues to be addressed. 

7.1 Practical Efficiency 

Similar to the traditional black-box testing algorithms to check 
conformance between Mealy machines, the theoretical (worst-case) 
complexities are high in order to achieve complete coverage. How- 
ever, worst-cases do not always occur in a practical system. In 
particular, we need to identify scenarios that our algorithms can 
be made more efficient. For instance, using existing ideas of ab- 
straction 1121 . we might obtain a smaller but equivalent model of 
the host system before running the algorithms. We might also, 
using additional partial information about the component, to de- 
rive a smaller state number for the component and to find ways 
to expedite the model-checking process. Notice that the number 
is actually the state number for a minimal automaton that has the 
same set input/output sequences as the component. Additionally, 
in the implementation, we also need a database to record the test 
results that have been performed so far (so repeated testing can 
be avoided). Algorithms are needed to make use of the test re- 
sults to aggressively trim the communication/witness graphs such 
that less test-cases are performed but the complete coverage is still 
achieved. Also, we will study algorithms to minimize communi- 
cation/witness graphs such that duplicate test-cases are avoided. 
Lastly, it is also desirable to modify our algorithms such that the 
communication/witness graphs are generated with the process of 
generating test-cases and performing black-box testing over the un- 
specified component X. In this way, a dynamic algorithm could be 
designed to trim the graphs on-the-fly. 

7.2 Coverage Metrics 

Sometimes, a complete coverage will not be achieved when run- 
ning the algorithms on a specific application system. In this case, a 
coverage metric is needed to tell how much the test-cases that have 
run so far cover. The metric will give a user some confidence on the 
partial model-checking results. Furthermore, such a metric would 
be useful in designing conservative algorithms to debug/verify the 
temporal specifications that sacrifice the complete coverage but still 
bring the user reasonable confidence. 

7.3 More Complex System Models 

The algorithms can be generalized to systems containing mul- 
tiple unspecified components. Additionally, we will also consider 
cases when these components interacts between each other, as well 
as cases when the host system communicates with the components 
asynchronously. Obviously, when the unspecified component (as 
well as the host system) has an infinite-state space, both the tra- 
ditional model-checking techniques and black-box techniques are 
not applicable. One issue with infinite-state systems is that, the in- 
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temal structure of a general infinite- state system can not be learned 
through the testing method. Another issue is that model-checking 
a general infinite-state system is an undecidable problem. It is 
desirable to consider some restricted classes of infinite-state sys- 
tems (such as real-time systems modeled as timed automata Q) 
where our algorithms generalize. This is interesting, since through 
the study we may provide an algorithm for model-checking driven 
black-box testing for a real-time system that contains an (untimed) 
unspecified component. Since the algorithm will generate test- 
cases for the component, real-time integration testing over the com- 
posed system is avoided. 
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APPENDIX 

A. DEFINITIONS 

Knv ■= {(s, s')\3 a £ r : (s, a, s') £ R}; 

RLmm ■= {0, s')|3 a € £, p £ V : (s, a, V, s') € R com m}; 

rys ._ rys i i rys 
J L • r\ env ^ *^comm> 

Rmv ~ TranstweClosure{R% nv ); 
R T := TranstiveClosure(R s ); 
Integer id := 1; 

B. ALGORITHMS 
B.l Liveness Analysis 

Procedure CheckIO((M, X),s ,s f ) 
N := ®; E := 0; 

If (s , Sf) £ Re nv A (sf, s f ) £ Rl nv Then 

Return "Yes"; 
Else if (s , s f ) (jL R T A (s f ,s f ) g R T Then 

Return "No"; 
End if 

N := {s|(s , s) £ R T A (s, s/) € # T )}; 
£ := {(s,s')|s,s' £ N : (s,o,s') £ i? ent) } 

U {(s,a/3, s')|s,s' £ TV : (s,a,f3,s') £ i? comm }; 
Return TestIO(X, reset, so, Sf, level = 0, count = 0); 
End procedure 

B.2 Union of Labeling Functions 

Procedure Union(Li, L 2 ) 
L := 0; 

For each s £ dom(Li) U dom(L2) Do 
If s £ dom(Li) n dom(L 2 ) Then 
IfLi(s) = lVL 2 (s) = IThen 

L:=LU{(s,l)}; 
Else 

L:=LU{(s,Li(s)VL 2 (s))}; 
End if 

Else if s £ dom(Li) Then 

L:=LU{(s,Li(s))}; 
Else 

L:=LU{(s,L 2 (s))}; 
End if 
End for 
Return L; 
End procedure 

B.3 Negation of a Labeling Function 

Procedure Negation(M, L\) 
L := 0; 

For each s € S Do 

If s £ dom(Li) Then 

L:=Lu{(s,l)}; 



Else if /(s) / 1 Then 

L:=LU{(s,-Li(s))}; 
End if 
Return L; 
End procedure 

B.4 Checking an EX Subformula 

Procedure HandleEX(M, Li) 
iV:=dom(Li);L:=0; 
For each £ £ dom(Li) Do 
For each s : R s (s,t) Do 
TV :=TVU{s} 

If Li(t) = 1 A R s env {s,t) Then 
If s £ dom(L) Then 
L:=LU{(s,l)}; 
Else if L(s) / 1 Then 

L:=L|.«-i; 
End if 
Else if s dom(L) Then 

L := Lu{(s,id)}; 
End for 
End for 
End if 

E := {(s, s')|s' £ dom(f) A 3a : (s, a, s') £ i? e „„} 

U{(s,a/3, s')|s' £ dom(f)A(s,a,/3, s') £ fc™}; 
Associate id with G = (TV, E, Li); id := id + 1; 
Return L; 
End procedure 

B.5 Checking an EU Subformula 

Procedure HandleEU(M, L±,L 2 ) 
L := L 2 ; 

Ti := dom(Li); T 2 := dom(L); 
While T 2 / Do 

Choose t £ T 2 ; T 2 := T 2 \ {t}; 
For each s £ Ti A i? s (s, t) Do 

IfLi(s) = 1 A L(t) = lAR s env (s,t) Then 
If s £■ dom(L) Then 

T 2 :=T 2 U{s};L:=LU{(s,l)}; 
Else if L(s) # 1 Then 

T 2 :=T 2 U{s};L:=L| s< _i; 
End if 
Else if s dom(L) Then 

T 2 := T 2 U {s}; L := L U {(s, id)}; 
End if 
End for 
End while 
TV := dom(L); 

E := {(s, s')|s, s' £ TV A 3a : (s, a, s') £ fl em ,} 

U {(s,a/3,s')|s,s' £ N A (s,a,/3,s') £ i? comm }; 
Associate id with G = (TV, E, Li, L 2 ); id := id + 1; 
Return L; 
End procedure 

B.6 Checking an EG Subformula 

Procedure HandleEG(X, it, s ,G= (N, E, L g )) 

SCCenv '• {C|C is a nontrivial SCC of M and G contains 
no communication transitions }; 

SCC comm := {G|G is a nontrivial SCC of M and G con- 
tains some communication transitions }; 

L := {(s,l)|3G £ SCC env : s £ G} 

U{(s,id)|3G £ SCCcomm : S £ G} 

T := dom(L); 
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While T / Do 

Choose t G T; T :=T\ {t}; 

For each s G dom(Li) A R a (s,t) Do 

UL(t) = 1 Ali(s) = 1 A R s env (s,t) Then 
If s dom(L) Then 

T:=TU{s};L := LU{(s,l)}; 
Else if L(s) j= 1 Then 

T:=TU{s};L~ L| s ^i; 
End if 

Else if s g dom(L) Then 

T :=TU{s};i:=iU{(s,irf)}; 
End if 
End for 
End While 
JV := dom(L); 

£ := {(s, s')|s, s' G N A 3a : (s, a, s') £ i? en „} 

U {(s,a/3,s')\s,s' € N A (s, a, (3, s') G R comm ); 
Associate id with G = (N, E, Li); id := id + 1; 
Return L; 
End procedure 

B.7 Testing an EX Graph 

The algorithm for testing an EX graph is simple. It first checks 
whether Li(s') can be evaluated true at any state s' such that the 
system can reach s' from so through an environment transition. It 
returns true if it is the case. Otherwise,it chooses one candidate 
from the set of all possible input symbols from so, and feeds the 
sequence n concatenated with the input symbol to X. If the out- 
put symbol of X and the input symbol matches the annotation of 
an edge originating from the node, it moves forward to try the des- 
tination node of the edge. If there is no match, then it tries other 
candidates. But before trying any other candidate, it brings X to its 
initial state by sending it the special input symbol, reset. The algo- 
rithm returns false when all candidates are tried without a match. 

Procedure TestEX(X, n, s ,G = (N, E, Li)) 
For each (so, s') G E : s' G dorn(Li) Do 
Experiment(X , resetn) ; 
IfTestVFG(X,7r,s',Li(s'))Then 

Return true; 
End if 
End for 

Inputs ■— {a|3/3 : (so, a/3, s') G E}; 
For each a G Inputs Do 
Experiment(X , resetn); 
f3 := Experiment(X,a); 
If 3s' : (s , a/3, s') £ E Then 

If TestWG{X,na,s' ^^s')) Then 

Return true; 
End if 
End if 
End for each; 
Return false; 
End procedure 

B.8 Testing an EU Graph 

The procedure TestEU keeps a sequence of input symbols n 
that has been successfully accepted by X and an integer level that 
records how many communications have been gone through with- 
out reaching a destination state. And the algorithm works as fol- 
lows. At first, it checks whether it has gone through more than 
mn communications without success, it returns false if it is the 
case. Then, it checks whether it has reached a destination state 
(i.e., s G dom(L2)). If it is the case, it returns true when I,2(so) 



can be evaluated true so. Next, it checks whether Li(so) can be 
evaluated true at so, it returns false if it is not the case. After that, 
it checks whether L\ (s') can be evaluated true at any state s' such 
that the system can reach s' from so through an environment tran- 
sition. It returns true if it is the case. Otherwise,it chooses one 
candidate from the set of all possible input symbols from so, and 
feeds the sequence n concatenated with the input symbol to X. If 
the output symbol of X and the input symbol matches the anno- 
tation of an edge originating from the node, it moves forward to 
try the destination node of the edge with level increased by 1. If 
there is no match, then it tries other candidates. But before trying 
any other candidate, it brings X to its initial state by sending it the 
special input symbol, reset. The algorithm returns false when all 
candidates are tried without a match. 

Procedure TestEU (X, n,so,G = (N , E , Li , L 2 ) , level) 
If level > mn Then 2 

Return false; 
Else if so G dom(Li) Then 

lfTestWG(X,n,s ,L 2 (s )) Then 

Return true; 
End if 

Else if not TestWG(X,n, s , Li(s )) Then 

Return false; 
End if 

For 3s' : (s ,s') G E Do 

Experiment(X , resetn); 

If TestEU (X,ir, s' , G, level) Then 
Return true; 

End if 
End for 

Inputs := {a|(so, a/3, s') G E}; 
For each a G Inputs Do 
Experiment(X , resetn); 
P := Experiment(X,a); 
If 3s' : (s , a/3, s') G E Then 

If TestEU { X, na, s' , G, level + 1) Then 

Return true; 
End if 
End if 
End for each; 
Return false; 
End procedure 

B.9 Subroutine for Testing an EG Graph 

The procedure SubTestEG keeps a sequence of input symbols 
that has been successfully accepted by X, an integer level that 
records how many communications have been gone through with- 
out reaching s/, and an integer count that indicates how many 
times Sf has been reached. It first checks whether it has gone 
through more than mn communications without reaching s/, it re- 
turns false if it is the case. Then, it checks whether it has reached 
the given state s/. If it is the case, it returns true when it has al- 
ready reached s / for m times, it increases count by 1 and resets 
level to when otherwise. The next, it tests whether Li(so) can 
be evaluated true at so, and it returns false if it is not the case. After 
that it checks whether Li(s') can be evaluated true at any state s' 
such that the system can reach s' from so through an environment 
transition. It returns true if it is the case. Otherwise, it chooses 
one candidate from the set of all possible input symbols from so, 
and feeds the sequence n concatenated with the input symbol to 

2 Here, n always denotes the maximal number of communications 
on any simple paths in G. 
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X. If the output symbol of X and the input symbol matches the 
annotation of an edge originating from the node, it moves forward 
to try the destination node of the edge with level increased by 1. 
If there is no match, it tries other candidates. But before trying 
any other candidate, it brings X to its initial state by sending it the 
special input symbol reset. The algorithm returns false when all 
candidates are tried without a match. 

Procedure 

SubTestEG(X,n,s ,Sf,G = (N, E, L\), level, count) 
If level > ran Then 2 

Return false; 
Else if so = 8f Then 
If count >= m Then 

Return true; 
Else 

count :— count + 1; level := 0; 
End if 

Else if not TestWG{X,n, s , Li(so)) Then 

Return false; 
End if 

For 3s' : (s ,s') <E E Do 
Experiment(X , resetir); 

If SubTestEG(X, n, s',s f , G, level, count) Then 

Return true; 
End if 
End for 

Inputs := {a\(so,a/3, s') G E}; 
For each a e Inputs Do 

Experiment(X , reset-it); 

(3 := Experiment(X,a); 

If 3s' : {s , a/3, s') € E Then 

If SubTestEG(X, -ira, s' ,Sf,G, level + 1, count) 

Then 

Return trite; 
End if 
End if 
End for; 
Return false; 
End procedure 

C. EXAMPLES 

C.l Check (M, x) |= AG(s 2 AFs 3 ) 

To check whether (M,X) \= AG(s 2 -> AFs 3 ), is equivalent 
to checking whether 

(M,X) |= -.£[true t/(s 2 A EG^s 3 )]. 

We describe how the formula 

/ = E[true U(s 2 A EG^s 3 )] 

is processed by HandleCTL from bottom to up as follows. 

1. the atomic subformula S2 is processed by HandleCTL, and 
a labeling function L\ — {(s2, 1)} is returned; 

2. the atomic subformula S3 is processed, and a labeling function 
Z/2 = {(S3, 1)} is returned; 

3. to process ^s 3 , HandleN 'egation is called with L2 to return 
a labeling function L a = {(s , 1), (si, 1), (s 2 , 1), (s 4 , 1)}; 

4. to process EG~>sz, HandleEG is called with L3 to con- 
struct an EG graph Gi = (N, E, L3) with id 2 (see Figure 

8) and return a labeling function L4 = {(so, 2), (si,2), (s2,2)}; 




Figure 8 



5. to process S2A-EG-1S3, HandleN egation and HandleUnion 
are called with L\ and L4 to return a labeling function L 5 = 

{(s 2 ,2)}; 

6. to process E[true U(s2 A _EG^s 3 )], HandleEU is called 
with L5 to construct an EU graph G2 = (N, E, L5) with id 
3 (see Figure 9) and return a labeling function 

L f = {(s , 3), (si,3), (s 2 ,3), (s 3 ,3), (s 4 ,3)}. 




Figure 9 



Since so is labeled by L f with an ID expression 3 instead of 1 
(i.e., true), we need to test whether the ID expression 3 can be 
evaluated true at so by calling TestWG with so and G2. It's easy 
to see that, essentially TestWG would be testing whether some 
communication trace (with bounded length) with two consecutive 
symbol pairs (send yes) is a run of X. It returns false if such 
trace exists, or vice versa. 

C.2 Check (M,x), So \= ag(s 2 -> AXA[-ns 2 Us 3 }) 

To check whether (M,X),s \= AG(s 2 -> AXA[-ns 2 Us a ]), 
is equivalent to checking whether 

(M,X) |= -nE[trueU(s2AEX(E[-ns :i U(s2A^S3)]VEG^s :i ))}. 
We describe how the formula 

/ = E[true U(s 2 A EX{E[^s 3 U(s 2 A -.S3)] V EG^s 3 ))] 
is processed by HandleCTL from bottom to up as follows. 

1. the atomic subformula S2 is processed by HandleCTL, and 
a labeling function L\ — {(S2, 1)} is returned; 

2. the atomic subformula S3 is processed, and a labeling function 
L2 = {(S3, 1)} is returned; 

3. to process ^s 3 , HandleN egation is called with L2 to return 
a labeling function L 3 = {(so, 1), (si, 1), (S2, 1), (s 4 , 1)}; 

4. to process S2 A ^s 3 , HandleN egation and HandleUnion 
are called with L\ and L3 to return a labeling function L4 = 

5. to process i?[^s 3 (7(s2 A ^s 3 )], HandleEU is called with 
L3 and L4 to construct an EU graph Gi = (N, E, Lz,L$) 
with id 2 (see Figure 10) and return a labeling function L 5 = 

{(so,2),(s 1 ,2),(s 2 ,l)}; 
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Figure 10 




Figure 11 



6. to process EG-1S3, HandleEG is called with L3 to con- 
struct an EG graph G2 = (N, E, L3) with id 3 (see Figure 
11) and return a labeling function Le = {(so, 3), (si, 3), (S2, 3)}; 

7. to process E[-iszU{si A ~<S2,)] V EG^sz, HandleUnion 
is called with L5 and Lq to return a labeling function L7 = 

{(ao,2V3),(fli,2V3),(fl2,l)}; 

8. to process .EX (£ [-.S3 f (s 2 A-.s 3 )] V.EG-.S3), HandleEX 
is called with L7 to construct an EX graph G3 = (N, E,Lj) 
with id 4 (see Figure 12) and return a labeling function Lg = 

{(so,4),(si,l),(s 2 ,4),(s3,4)}; 




Figure 13 

Figure 12 



9. to process S2Ai5X(_E[-iS3(7(s2 A^s 3 )]Vi5G-iS3), HandleNegation 
and HandleU nion are called with Li and Lg to return a la- 
beling function Lg — {(s2,4)}; 

10. toprocsssE[trueU(s2AEX(E[-nS: i U(s 2 A^sa)]VEG^s: i ))l 
HandleEU is called with Lg to construct an EU graph G4 = 
(N,E,L 5 ) with id 5 (see Figure 13) and return a labeling 
function 

L f = {(s , 5), (si, 5), (s 2 , 5), (s 3 , 5), (s 4 , 5)}. 

Since so is labeled by Lf with an ID expression 5 instead of 1 
(i.e., true), we need to test whether the ID expression 5 can be 
evaluated true at so by calling TestWG with so and G4. It's easy 
to see that, essentially TestWG would be testing whether some 
communication trace (with bounded lengtg) with two consecutive 
symbol pairs (send yes) is a run of X. It returns false if such 
trace exists, or vice versa. 
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